home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 734 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.1 KB
  1. From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
  2. Date: Wed, 29 Dec 93 12:36:01 +0100
  3. Message-Id: <9312291136.AA16739@issan.informatik.uni-dortmund.de>
  4. To: mint@atari.archive.umich.edu
  5. In-Reply-To: <m0pEwCz-0000bTC@sdf.lonestar.org> (ekl@sdf.lonestar.org)
  6. Subject: Re: file systems
  7.  
  8. On Wed, 29 Dec 93 2:24:44 CST, ekl@sdf.lonestar.org (Evan K. Langlois) said:
  9.  
  10. |> Anyway, I noticed that loaded file systems return a -33 and not a -34
  11. |> when a non-existing path is accessed.  I haven't seen a fix in th 1.09
  12. |> diffs, but its definately a bug (its also why STZIP doesn't create folders).
  13.  
  14. Well, it's a bug in STZIP.
  15.  
  16. |> Now, I looked at the MiNT code, and decided that didn't help since it
  17. |> looked fine.  I looked at the ramfs code, and noticed that the "lookup"
  18. |> function that "relpath2cookie" was calling didn't differenciate between
  19. |> a directory or a file.  So, when the name wasn't found, it returned -33,
  20. |> and I would assume that minixfs does the same thing (since it too returns
  21. |> -33 instead of -34 from the relpath2cookie call).  Now, what I'd like to
  22. |> know, is how the filesystem can determine if the name its looking for is
  23. |> a directory or filename?  And if it can't then shouldn't the MiNT kernel
  24. |> change a -33 (EFILNF) to -34 (EPTHNF) when the name being looked-up is
  25. |> a directory?
  26.  
  27. I think using EFILNF is the right thing to do. At least it is
  28. consistent with the meaning of ENOENT on Unix. There is also ENOTDIR
  29. which is returned if a path component exists but is not a directory. I
  30. think this corresponds to EPTHNF, and this is what MiNT returns in
  31. this case.  Note that GEMDOS (i.e. tosfs) works the same.
  32.  
  33. |> Also, before my absense everyone seemed to be talking about the Fseek
  34. |> differences.  All the filesystems seem to handle it differently.  The
  35. |> procfs has some stuff changed I think, but in any case, ramfs code or stzip
  36. |> needs to be changed (was this already done?  Which way is correct?)       
  37.  
  38. The correct way is to always *add* the offset to the starting point
  39. (start of file, current position or end of file).  Note that a
  40. positive offset with SEEK_END is meaningfull, e.g. on MinixFS or RamFS.
  41.  
  42.